Q: What SAP types are there?
A: x4 - File server
x2E - TCP/IP service
x47 - Novell print server
x107 - Remote console netware driver (RSPX)
x30C - Print sharing device
x4808 - Sitelock.nlm
Q: What is the meaning of "poison SAP" in the show ipx traffic command?
A: A SAP poison (or poison SAP) is a SAP update that is sent by an IPX device. When the IPX device no longer hears a service, it notifies the network that that service is unreachable. It is the same as a regular SAP update except that the hop count is set to 16. It is completely normal to see a non-zero number of poison SAPs in the show ipx traffic command output. This would happen anytime a router (the path to a service) or a PC (the service itself) was rebooted or for some reason became unreachable.
Q: How do Cisco routers handle poison SAPs?
A: Part 1: 9.1 Poison SAP handling
A: Part 2: 9.21 and Later Poison SAP handling
9.21 and later behavior conforms to the "IPX Router Specification" from Novell, Inc.
Q: How does a Cisco router pick the server to include in a Get Nearest Server response?
A: Part 1: 9.1 Behavior
The server of the requested type with the lowest hopcount is considered the "nearest" server. If more than one server of the requested type shares the lowest hopcount, then the first one in the SAP table is chosen. New servers of the same type and hopcount as one that already exists in the table are placed in the table ahead of the existing entry. Let's look at a sample SAP table:
Total Novell Servers: 1Responses to Get Nearest Server requests for type 4 would contain MAGNOLIA. If a new server of type 4 also one hop away was learned, the table would look like this:Type Name Net Address Port Hops Interface 4 MAGNOLIA 42.0000.0000.0001::0451 1 Ethernet2
Total Novell Servers: 1Now future responses to Get Nearest Server requests for type 4 will contain NEWSERVER instead of MAGNOLIA.Type Name Net Address Port Hops Interface 4 NEWSERVER AA.0000.0000.0001::0451 1 Ethernet1 4 MAGNOLIA 42.0000.0000.0001::0451 1 Ethernet2
A: Part 2 9.21 and Later Behavior
The server of the requested type with the lowest route metric is considered the "nearest" server. If more than one server of the requested type shares the lowest metric, then the first one in the SAP table is chosen, unless gns round robin processing of GNS responses is enabled. New servers of the same type and metric as one that already exists in the table are placed in the table ahead of the existing entry. If GNS round robin is enabled, then replies will be balanced among the servers of that type with equal route metrics. For example, look at this SAP table:
1 Total IPX ServersResponses to Get Nearest Server requests for type 4 would contain MAGNOLIA. If a new server of type 4 with the same metric was learned, then the table would look like this:Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf P 4 MAGNOLIA 42.0000.0000.0001::0451 3/02 2 Et2
2 Total IPX ServersNotice that the 9.21 and later table is sorted by name order with the equal cost types. To see the table in the order GNS replies would be used, use the command show ipx server unsort.Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf P 4 MAGNOLIA 42.0000.0000.0001::0451 3/02 2 Et2 P 4 NEWSERVER AA.0000.0000.0001::0451 3/02 2 Et1
router>show ipx server unsort
Codes: S - Static, I - Incremental, P - Periodic, H - Holddown
2 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
P 4 NEWSERVER AA.0000.0000.0001::0451 3/02 2 Et1
P 4 MAGNOLIA 42.0000.0000.0001::0451 3/02 2 Et2
Now future responses to Get Nearest Server requests for type 4 will
contain NEWSERVER. If another new server with the same metric is heard
from, the table would look like this:
3 Total IPX ServersAnd the unsorted order looks like this:Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf P 4 ANEWSERVER AB.0000.0000.0001::0451 3/02 2 Et1 P 4 MAGNOLIA 42.0000.0000.0001::0451 3/02 2 Et2 P 4 NEWSERVER AA.0000.0000.0001::0451 3/02 2 Et1
3 Total IPX ServersThe first GNS request for type 4 service will be answered with ANEWSERVER, the second GNS request will be answered with NEWSERVER, the third request will be answered with MAGNOLIA, and the fourth will be answered with ANEWSERVER.Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf P 4 ANEWSERVER AB.0000.0000.0001::0451 3/02 2 Et1 P 4 NEWSERVER AA.0000.0000.0001::0451 3/02 2 Et1 P 4 MAGNOLIA 42.0000.0000.0001::0451 3/02 2 Et2
Q: How does IPX load balancing work on the Cisco router?
A:
| ------------ ------------ |
|---| router A |--\--| router C |---|
| ------------ | ------------ ------------ | ------------
|---| router Z |---| |---| router X |
| ------------ | ------------ ------------ | ------------
|---| router B |--\--| router D |---|
| ------------ ------------ |
If router Z is configured with ipx max-paths 2 and routers A and B will
get you to the same destination network in the same route metric (router
X), router Z will send packets to that destination alternating between the
two paths, both with IPX slow switching and IPX fast switching. When IPX
autonomous switching or IPX SSE switching are enabled, load balancing
takes place on a per destination basis, as it does with TCP/IP balancing.
Q: Does PBURST mode, which allows multiple packets to be outstanding without an acknowledgment, affect load balancing?
A: The Novell Clients and Servers are the only devices which are involved in PBURST/LIPx negotiations. The Cisco is free to pick whatever path it thinks is best for the packet, so if ipx maximum-path is greater than one, packets may take different path and arrive out of order. The destination station has to deal with re-ordering packets. Older versions of NetWare do not handle out-of-order packets very well. Make sure you are running the latest patches concerning PBURST/LIPx and the latest NLMs for optimum PBURST/LIPx performance.
Q: How do I flood IPX global broadcasts?
A: Part 1: 9.1 Behavior
When Cisco routers "helper" packets, using the helper-address feature, the router forwards the broadcast packet received to the IPX address configured in the helper-address command on that interface. In the case of flooding, the helper address is -1.ffff.ffff.ffff on the receiving interface, and the packet will be sent out all other interface running IPX, with the network number of that interface placed in the source network field of the packet.
For example, if your IPX network contains 10 IPX network segments but only two of those segments will be flooded with IPX/NetBIOS traffic, you might configure specific network addresses on the helper-address.
Interface ether 0
ipx network 1000
ipx helper-address 1011.ffff.ffff.ffff
On the distant network you might have this configuration:
Interface ether 0
ipx network 1011
ipx helper-address 1000.ffff.ffff.ffff
These broadcasts are seen only on network segments 1000, 1011, and the
networks between them (the routed path between them). If -1.ffff.ffff.ffff
(flooding) is used, then broadcasts will be sent on all 10 of the network
segments.
Multiple helper addresses for IPX are supported in release 9.1 and higher.
A: Part 2: 9.21 Behavior
Apply the ipx type-20-propagation command to all interfaces which need to receive or send these packets. See chapter 19 of the Router Products Configuration Guide for more information on Novell NetBIOS/Type-20 propagation facilities.
In newer maintenance releases the command ipx type-20 helpered turns off the 9.21 and later type-20-propagation handling of these packets and uses the 9.1 style of needing ipx helper-address configuration in order to forward these packets.
Q: How do I prevent flooded packets from being endlessly circulated through my network?
A: The topology where this can occur is when you are flooding (not helpering via directed addresses) and there are multiple paths back to the source of the NETBIOS packet. There are cases where looping of some broadcast packets might occur. Guards can be put in place to prevent unwanted extra broadcasts which are a part of normal IPX/NetBIOS traffic:
netbios-socket-input-checks Limit input of non-type 20 netbios
bc packets
type-20-input-checks Do additional input checks on type 20
propagation packets
type-20-output-checks Do additional output checks on type 20
propagation packets
For example, perhaps you only want IPX type-20 packet broadcasts
forwarded, and not the broadcasts used by the original shareware version
of the network game Doom. On an IOS 10.2-based system you could create a
helper list which uses the access-list 901:
access-list 901 permit 20 -1 0 -1 0
access-list 901 deny -1
Q: What are IPX "ticks" and does Cisco use them in calculating delay?
A: A tick is a unit of delay roughly 1/18th of second long; there are 18.21 ticks in a second. Ticks are used to measure how long it takes a packet to reach a destination. The ticks field of an IPX route is always at least one. Its value is used by the NetWare shell to determine how long it should wait for a response from a file server and by NetWare routers to make routing decisions.
In 9.1 we carry ticks information in the routing table but do not use it to decide the best route to a destination. Instead we use the hop count to that network. The additional ticks to add to a route going through a cisco in 9.1 are based on the interface delay setting.
In 9.21 and later IOS releases, ticks are the primary routing metric to determine the best path to a destination. The additional ticks to add to a route going through a Cisco are determined by the "ipx delay x" configured for that interface. By default, all LAN interfaces have ticks values of 1, and all WAN interfaces have ticks values of 6. For dynamic calculation of ticks for WAN interfaces, use IPXWAN, which is supported in release 10.0 and later.
Q: What does "format error" mean in the "show ipx traffic" display?
A: A format error occurs when a router receives an IPX packet with a different IPX encapsulation type than the router's interface, or when the length of the received packet is smaller than 30 bytes or larger than the interface Maximum Transmission Unit (MTU).
Q: Could you explain the "ipx routing" command?
A: The address in the command novell routing [address] is only relevant for non-IPXWAN serial lines. Interfaces with a Mac layer hardware address will use that address as the IPX host address. Serial lines that do not have a Mac layer hardware address will use the address specified in the "ipx routing" command. If no address is specified in the "ipx routing" command, then the Mac address of the first IEEE interface will be used as the host address. If there are no IEEE interfaces on the router or they are not up when ipx routing is enabled, the system will generate a random pseudo-Mac address to use.
hostname Router
!
enable password SwR4dWeQ
!
ipx routing 0000.0c19.2b58
!
interface Serial 1
ipx network FC01
...
Router>show ipx int ser 1
Serial1 is up, line protocol is up
IPX address is FC01.0000.0c19.2b58 [up] line-up, RIPPQ: 0, SAPPQ: 0
...
IPXWAN uses a different method to determine its IPX host address. Se
RFC1634 for details.
Q: How do I configure IPX over Frame Relay?
A: Use these commands:
int serial 0
encap frame-relay
ipx network 100
frame-relay inverse-arp ipx DLCI
You might have to map a Data Link Connection Identifier (DLCI) to the IPX
address if the remote router does not support Inverse-Arp. This example
maps the remote router with an IPX address of 100.0000.0c00.1122 to DLCI
123.
frame-relay map novell 100.0000.0c00.1122 123 broadcast
Q: What about all the Novell Ethernet encapsulation types?
A: Frame Type ETHERNET_802.3 is Novell's proprietary encapsulation. They put SPX/IPX packets directly within 802.3 frames; they do not use 802.2 LLC or SNAP. The result is non-standard, and can cause problems when mixed with "real" 802.3/.2 traffic. This is called "Novell Encapsulation NOVELL-Ether" in Cisco's terminology.
Frame Type ETHERNET_II is "standard" Ethernet II framing. The SPX/IPX packets are encapsulated into Ethernet II frames using type code 8137. These frames are the same as the Novell frames except for the two-octet type code/frame length field. This is called "Novell Encapsulation ARPA" in Cisco's terminology.
Frame type ETHERNET_SNAP, or Cisco Novell Encapsulation SNAP, is an Ethernet packet with a SNAP header.
Frame type ETHERNET_802.2, or Cisco Novell Encapsulation SAP, is real 802.3 encpasulation with 802.2 LLC. This is Novell's new standard default encapsulation in NetWare 3.12 and NetWare 4.x. Cisco's default encapsultation for IPX frames on Ethernet is still novell-ether, or in Novell's nomenclature ETHERNET_802.3.
router(config-if)# ipx encapsulation?
arpa Novell Ethernet_II
HDLC HDLC on Serial Links
novell-ether Novell Ethernet 802.3
sap IEEE 802.2 on Ethernet, Token Ring, and FDDI
snap IEEE 802.2 SNAP on Ethernet, Token Ring, and FDDI
Click here for
Novell encapsulation types for other media.
Q: What if I have lots of Novell traffic on my network but I need to turn on debugging?
A: Disable logging to the console, and log to a syslog server. You would use the following commands in configuration to do this:
no logging console
logging "ip address of syslog server"
Q: How do I use a mask for IPX network numbers in an access-list?
A: In 9.1, there is no mask for the network number; the masks are for source and destination addresses. The syntax for the access-list is:
access-list number {deny|permit} novell-source network[.source-address [source-mask]]
novell-destination-network[.destination-address [destination-mask]]
In order to allow all network numbers starting with 817axxxx (817a0000 -
817affff), you have to type in all network numbers.
access-list 801 permit 817a0000
access-list 801 permit 817a0001
...
access-list 801 permit 817affff
In 9.21 and later, allowing all network numbers starting with 817axxxx
(817a0000 - 817affff) is much easier because of network masks. Network
masks are permitted on 900 (extended access-lists) and 1000 SAP filter
access-lists. Here's the syntax for the command:
access-list access-list-number {deny | permit} protocol [source-nmetwork[.source-node[source-network-mask.]source-node-mask] source-socket[destination-network[.destination-node[destination-network-mask. destination-node-mask]destination-socket]]
And here's an example:
access-list 901 permit -1 817a0000.0000.0000.0000 ffff.ffff.ffff.ffff
Q: Don't you have to enable DECnet before Novell on Cisco routers running both protocols?
A: Before 8.2, when DECnet was started on a router, all of the router's interfaces were changed so that the Mac level address fell within the DEC range. This meant that DECnet had to be started before any other protocol that used the Mac address as part of its protocol address (like Novell and XNS). 8.2 changed the DECnet implementation so that only the interfaces that were assigned a DECnet cost had their Mac address changed. If you are going to run DECnet and Novell on the same interface, you need to start the DECnet first. To be safe, you should always start DECnet first in a mixed environment.
Q: Is Cisco aware of BIGPACK.NLM and PBURST.NLM, and are they supported?
A: Novell has told us about a Netware Loadable Module that operates on the fileserver and newer Client software. At one time this NLM was in two parts: Burst mode and Lare packet negotiation support. Both parts are now bundled into the same NLM called PBURST.NLM. NetWare 3.12 and NeWare 4.x have PBURST/LIPx built into the NOS.
PBURST.NLM is designed to compensate for a problem with NetWare 3.11 or earlier Clients/Servers. When the workstation logs in or attaches to a fileserver, the workstation and server must negotiate a Maximum Packet Size value. This will be the workstation's Packet Buffer Size or the file server's Packet Buffer Size, whichever is smaller. If there is a router between the fileserver and workstation, a default size of 576 bytes is used, because the fileserver cannot determine if all routers and segments in the path can handle a large packet size.
The LIPx part of PBurst intercepts the Negotiate Packet Size request, and duplicates the procedure above exactly, except that it ignores the router check. After LIPx has been loaded on the fileserver, all workstations attaching will use the largest negotiated packet size, regardless of the intervening routers. Since there is no router check, there is a possibility of a session establishment failure if all the intervening routers are not properly configured.
Packet Burst IPX/NCP is completely independent of the Cisco router. Tests have been performed with current releases of our software and no problems have been observed. End-to-end IPX throughput has increased using burst mode, which increases the number of packets that can be sent before an ACK is required.
Q: Do Novell NetBIOS packets require helper-lists?
A: Novell's NetBIOS runs over IPX. The initial NetBIOS queries generally take the form of local broadcasts and, in 9.1, require a helper address to reach the target server. Once a helper address has been applied to an interface, NetBIOS will be forwarded to the address defined in the helper-address. In 9.21 and later, Novell NetBIOS broadcasts are forwarded using the ipx type-20-propagation command.
Q: What are all the possible protocol and socket values for extended access-lists?
A: The Cisco router can filter on ANY value in the "protocol" and "socket" fields in the access list. Here are some well-known values for these fields:
IPX protocol (or packet) types:
0 Unknown (could be any of the below, check socket to see what it is)
1 Routing information protocol (RIP)
2 Echo packet (ping)
4 Internet Packet Exchange (IPX)
5 Sequenced Packet Exchange (SPX)
17 NetWare Control Protocol (NCP)
20 NetBIOS Name Packet
Novell socket numbers:
0x451 NCP
0x452 SAP
0x453 RIP
0x455 NetBIOS
0x456 Diagnostics
0x457 Serlialization Packets
0x4000 - 0x6000 Ephemeral sockets; used for interaction with file
servers and other network communications
0x8000 - above Sockets assigned by Novell to third parties or
themselves.
Q: How big are IPX RIP and SAP updates?
A: The size of an IPX RIP packet generated by a Cisco device is up to 50 eight-byte RIP entries plus 32 bytes of IPX overhead (for a total of 432 bytes), plus media encapsulation overhead.
The size of an IPX SAP packet generated by the Cisco router will be up to seven 64-byte SAP entries plus 32 bytes of IPX overhead (for a total of 480 bytes), plus the media encapsulation overhead.
Q: What does "uses" mean in the IPX routing table?
A: The "uses" counter associated with each route is incremented each time that route is chosen as the path for an IPX packet. It doesn't necessarily mean that that many packets have been successfully sent using that route, only that the route was chosen that many times. It is still possible after the "uses" counter is incremented to discard the packet due to exceeded MTU size for the output interface, output access-list failure, a full output queue, etc.
Q: What SAP type do I have to allow for RCONSOLE to work?
A: RCONSOLE sends out a "General Services Query" for type 0x107 servers. The Cisco router must be permitted to announce type 0x107 servers for RCONSOLE to work on the PC.
Q: How is IPX fast-switching implemented?
A: IPX fast-switching is based on information in the fastswitch cache. Entries are created based on information derived from the first process-switched packet to a given destination. When the destination is on a directly connected network, or "ipx maximum paths" is set to 1 (the default) there can never be more than one fastswitch cache entry to a given destination.
However, when "maximum paths" is set to a value larger than 1, multiple equal cost routes (to remote networks) may be kept in the routing table. In this case, multiple fastswitch cache entries will be created as well.
In the presence of multiple cache entries the IPX fastswitch algorithm is simple: we round-robin between entries.
Here is sample output from show ipx cache:
Destination Interface MAC Header
* 365.0000.0c02.8cf9 Ethernet0 00000C028CF900000C028CFB8137
* 164.0000.0c01.d878 TokenRing0 000030802D7D0000304060DFE0E003
@TokenRing1 000030802D7E0000304060DFE0E003
Successive packets destined for 164.0.0c01.d878 will be sent via TR0, then
TR1, then TR0, etc.
In 9.0 and 8.3, the round-robin algorithm is the same. However, the fastswitch cache destination is kept per network, not per host. So it should look something like this:
Destination Interface MAC Header
* 365 Ethernet0 00000C028CF900000C028CFB8137
* 164 TokenRing0 000030802D7D0000304060DFE0E003
@TokenRing1 000030802D7E0000304060DFE0E003
Consequently, you should see a slight difference in the fastswitch
behavior when load sharing is enabled. Successive incoming packets
destined for a given remote network will be sent out eligible interfaces
on a round-robin basis. However, the packets for a given host would be
distributed between interfaces depending upon the mix of traffic destined
for the remote network.
Q: Is there a way to control which server answers the GNS request?
A: We answer GNS requests in 9.1 with the Server which appears at the top of the Service table. To change which Service is at the top of the table in 9.1, you can either filter that service out completeley with an input-sap-filter (then no one would be able to access that server through this router), or you can define a static SAP for the service you want to appear at the top of the table. To do this, give that static SAP a lower hop count than the server which is at the top of the table for that service type. Or, make the server which is at the top of the list lower down in the table by defining a static SAP for that service which makes its hop count farther away.
In 9.21 and later the best way to control which server answers a GNS response is by using an output-gns-filter.
Q: Does Cisco support Novell's "preferred server" command?
A: Sort of. The preferred server command on the Client is used like this: